NAT'L INST. OF STAND & TECH
I NIST
lllDb M3LfiE7 P^BUCATIONS
NIST Special Publication 800-25
Nisr
National Institute of Standards
and Technology
Technology Administration
U.S. Department of Commerce
Federal Agency Use of Public
Key Technology for Digital
Signatures and Authentication
Kathy Lyons-Burke
Federal Public Key Infrastructure Steering Committee
COMPUTER
SECURITY
rhe National Institute of Standards and Technology was established in 1988 by Congress to "assist industry in
the development of technology . . . needed to improve product quality, to modernize manufacturing processes,
to ensure product reliability . . . and to facilitate rapid commercialization ... of products based on new scientific
discoveries."
NIST, originally founded as the National Bureau of Standards in 1901, works to strengthen U.S. industry's
competitiveness; advance science and engineering; and improve public health, safety, and the environment. One
of the agency's basic functions is to develop, maintain, and retain custody of the national standards of
measurement, and provide the means and methods for comparing standards used in science, engineering,
manufacturing, commerce, industry, and education with the standards adopted or recognized by the Federal
Government.
As an agency of the U.S. Commerce Department's Technology Administration, NIST conducts basic and
applied research in the physical sciences and engineering, and develops measurement techniques, test
methods, standards, and related services. The Institute does generic and precompetitive work on new and
advanced technologies. NIST's research facilities are located at Gaithersburg, MD 20899, and at Boulder, CO 80303.
Major technical operating units and their principal activities are listed below. For more information contact the
Publications and Program Inquiries Desk, 301-975-3058.
Office of the Director
• National Quality Program
• International and Academic Affairs
Technology Services
• Standards Services
• Technology Partnerships
• Measurement Services
• Information Services
Advanced Technology Program
• Economic Assessment
• Information Technology and Applications
• Chemistry and Life Sciences
• Materials and Manufacturing Technology
• Electronics and Photonics Technology
Manufacturing Extension Partnership
Program
• Regional Programs
• National Programs
• Program Development
Electronics and Electrical Engineering
Laboratory
• Microelectronics
• Law Enforcement Standards
• Electricity
• Semiconductor Electronics
• Radio-Frequency Technology'
• Electromagnetic Technology'
• Optoelectronics'
Materials Science and Engineering
Laboratory
• Intelligent Processing of Materials
• Ceramics
• Materials Reliability'
• Polymers
• Metallurgy
• NIST Center for Neutron Research
Chemical Science and Technology
Laboratory
• Biotechnology
• Physical and Chemical Properties^
• Analytical Chemistry
• Process Measurements
• Surface and Microanalysis Science
Physics Laboratory
• Electron and Optical Physics
• Atomic Physics
• Optical Technology
• Ionizing Radiation
• Time and Frequency'
• Quantum Physics'
Manufacturing Engineering
Laboratory
• Precision Engineering
• Automated Production Technology
• Intelligent Systems
• Fabrication Technology
• Manufacturing Systems Integration
Building and Fire Research
Laboratory
• Applied Economics
• Structures
• Building Materials
• Building Environment
• Fire Safety Engineering
• Fire Science
Information Technology Laboratory
• Mathematical and Computational Sciences^
• Advanced Network Technologies
• Computer Security
• Information Access and User Interfaces
• High Performance Systems and Services
• Distributed Computing and Information Services
• Software Diagnostics and Conformance Testing
• Statistical Engineering
'At Boulder, CO 80303.
^Some elements at Boulder, CO.
NisT Special Publication 800-25 Federal Ageiicy Use of Public Key
Technology for Digital Signatures
and Authentication
Kathy Lyons-Burke
Federal Public Key Infrastructure Steering Committee
COMPUTER SECURITY
Computer Security Division
Information Technology Laboratory
National Institute of Standards and Technology
Gaithersburg, MD 20899-8930
October 2000
U.S. Department of Commerce
Norman Y. Mineta, Secretary
Technology Administration
Dr. Cheryl L. Shavers, Under Secretary of Commerce for Technology
National Institute of Standards and Technology
Raymond G. Kammer, Director
Reports on Information Security Technology
The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST)
promotes the U.S. economy and public welfare by providing technical leadership for the Nation's measurement and
standards infrastructure for information technology. ITL develops tests, test methods, reference data, proof of concept
implementations and technical analyses to advance the development and productive use of information technology.
ITL's responsibilities include the development of technical, physical, administrative, and management standards and
guidelines for the cost-effective security and privacy of sensitive unclassified information in federal computer systems.
This Special Publication 800 series reports on ITL's research, guidance, and outreach efforts in computer security, and
its collaborative activities with industry, government, and academic organizations.
National Institute of Standards and Technology Special Publication 800-25
Natl. Inst. Stand. Technol. Spec. Publ. 800-25, 33 pages (Oct. 2000)
CODEN: NSPUE2
U.S. GOVERNMENT PRINTING OFFICE
WASHINGTON: 2000
For sale by the Superintendent of Documents, U.S. Government Printing Office, Washington, DC 20402-9325
Table of Contents
1. PURPOSE 1
2. BACKGROUND 2
3. ACCESS CERTIFICATES FOR ELECTRONIC SERVICES 5
4. USING THIS DOCUMENT 5
5. SUMMARY 6
Question 1. What are the benefits, direct and indirect, financial and non-
financial, OBJECTIVE AND SUBJECTIVE, OF USING DIGITAL SIGNATURES FOR THE PROPOSED
APPLICATION? 7
Question 2. How much will it cost to (a) either convert an existing electronic
PROCESSING SYSTEM (THAT IS, A SYSTEM WHICH PROCESSES INFORMATION ELECTRONICALLY
OR DIGITALLY) TO USE DIGITAL SIGNATURES, OR CONVERT AN EXISTING NON-ELECTRONIC
PROCESS TO AN ELECTRONIC ONE USING DIGITAL SIGNATURES; AND (B) OPERATE SUCH A
system after conversion? 9
Question 3. What are the risks associated with the use of public key technology
FOR this application? 18
Question 4. How should the benefits determined in response to Question 1 be
COMPARED TO THE COSTS ESTABLISHED IN RESPONSE TO QUESTION 2 AND THE RISKS
discussed IN RESPONSE TO QUESTION 3? 22
Question 5. What are the critical implementation issues that an agency should
consider as it seeks to implement and use a pki for digital signatures? 24
APPENDIX (1): DESCRIPTION OF PUBLIC KEY TECHNOLOGY AND THE PUBLIC
KEY INFRASTRUCTURE 27
APPENDIX (2): DESCRIPTION OF PUBLIC KEY CERTIFICATES AND THE
CERTIFICATION PROCESS 29
111
1. Purpose
This guidance document was developed by the Federal Public Key hifrastructure Steering
Committee to assist Federal agencies that are considering the use of public key technology
for digital signatures or authentication over open networks such as the hitemet. This includes
communications with other Federal or non-Federal entities, such as members of the public,
private firms, citizen groups, and State and local Governments. Most public key technology
applications for digital signatures provide for user authentication as well. However, public
key technology can be used for user authentication only without digital signatures. Standards
such as X.509 Version 3 (hitemational Telecommunication Union Recommendation X.509
(03/00) - hiformation technology - Open systems interconnection - The directory: public-key
and attribute certificate frameworks) provide for that functionality.
This document encourages the thoughtfiil use of public key technology by Federal agencies as
set forth in guidance published by the Office of Management and Budget implementing the
Government Paperwork Elimination Act (GPEA) (Public Law 105-277; Federal Register
Notice, Volume 65, Number 85). GPEA requires Federal agencies, by October 21, 2003, to
allow individuals or entities that deal with an agency the option to submit information or
perform transactions with an agency electronically, when practicable, and to maintain records
electronically, when practicable. The Act specifically states that electronic records and their
related electronic signatures are not to be denied legal effect, validity, or enforceability
merely because they are in electronic form, and encourages Federal Government use of a
range of electronic signature alternatives. This document also amplifies upon principles
contained in the GPEA guidance and separately in Access with Trust issued in September
1998 by the Office of Management and Budget, the National Partnership for Reinventing
Government, and the Government hiformation Technology Services Board. Finally, it
discusses briefly the Government-wide Public Key hifrastructure (PKI) which is developing
to enable applications programs to effectively use public key technology across Federal
agencies.
Specific questions and issues are discussed to help agencies: (1) evaluate their potential
applications of public key technology involving digital signatures or authentication,
considering whether the application warrants such use as set forth in the 0MB GPEA
guidance; and (2) implement those applications selected. The questions and issues address
technical, business, policy, and legal aspects, and they are fashioned to inform all agency
elements who play a part in evaluating how public key technology may be applied to agency
operations. While many of the factors addressed are also relevant to other (non-PKI)
technologies used to support electronic transactions (e.g.. Personal Identification Numbers),
the focus of this document is the use of public key technology for digital signatures or
authentication over open networks.
This document responds to the Office of Management and Budget (Federal Register Notice,
Volume 65, Number 85) guidance on implementing the Government Paperwork Elimination
Act. The guidance broadly addresses how agencies should assess the costs, benefits, and risks
when moving to electronic processes. It also directs the Federal Public Key Infrastructure
Steering Committee to publish technical guidance on the use of public key technology for
1
digital signatures or authentication. 0MB has requested that other agencies issue related
guidance on GPEA implementation. The Department of the Treasury is addressing policies
and practices for electronic transactions and authentication techniques in Federal payments
and collections; the Department of Justice is issuing guidance analyzing legal issues of
electronic processes; and the National Archives and Records Administration (NARA) is
providing guidelines on the management, preservation, and disposal of electronic Federal
records when using electronic signatures. Readers are referred to those other documents for
authoritative guidance on the issues they address.
2. Background
Lidividuals (including Federal employees) or other entities interacting with Federal agencies
electronically where there is a need for a secure transaction should have reasonable assurance
that:
(1) the information sender and recipient both will be identified uniquely so the parties
know where the information is coming from and where it is going (identification
and authentication);
(2) the transmitted information was not altered deliberately or inadvertently (data
integrity);
(3) there is a way to establish that the sender's identity is inextricably bound to the
information (technical non-repudiation); and
(4) The information will be protected from unauthorized access (confidentiality or
privacy). This functionality is included for completeness since public key
technology and a Public Key Infrastructure provide it; however, confidentiality and
privacy concerns are not covered in detail in this guidance.
Two parties who may not know each other should be able to communicate reliably through
electronic means, with confidence that their communication is protected and their identities
are established with neither party being impersonated. They should also have assurance that
their communication cannot be repudiated after it has occurred.
Public key technology enables applications software (programs) to meet these requirements.
While a full description of the technology and how it works is beyond the scope of this
document, a brief description can be found in Access with Trust and in a separate, more
recent report. The Evolving Federal Public Key Infrastructure (both available at http.V/gits-
sec.treas.gov).
Public key technology has a firm theoretical underpinning and a growing spectrum of
applications, but its use represents unexplored territory for many Federal agencies. Natural
reluctance may exist until the "bugs have been shaken out" by someone else. Access with
Trust and The Evolving Federal Public Key Infrastructure describe how that "shaking ouf
process is well underway and succeeding in making public key technology in general, and
2
digital signatures in particular, useful to Federal agencies today. Federal agencies
considering the use of public key technology will benefit by proceeding promptly to
participate in building the Federal portion of the evolving worldwide PKI. This will enable
agencies to develop applications around their needs, rather than adjusting those needs later to
an evolving framework.
Decisions to apply PKI technology may be made for an agency if it postpones employing the
technology in its applications software. Agencies may be forced to implement a specific PKI
solution in order to interact with external entities that use a PKI. For example, the automobile
industry, through the Automotive Network Exchange (ANX) and the International Computer
Security Association (ICSA), is implementing a PKI for interactions with suppliers. In
addition, the financial sector, through the National Automated Clearing House Association
and through multi-bank consortia (one example is a multi-bank consortium under Identrus),
is implementing PKI solutions for inter-bank interactions; and the health care sector, through
hospitals, insurers, pharmacists, and others, is also implementing PKIs. The best way for
Federal agencies to become full participants in the construction of the framework is to apply
public key technology now to substantive agency work, just as companies in the industrial,
financial, and health care sectors are doing for their spheres of interest.
As with any investment in new technology, the agency needs an appropriate business case
linked to its mission and goals. An agency must ask itself whether the PKI functionality
needs to be added for a specific Government fiinction, whether it should be performed within
the agency or through contractors or outsourcing, and whether the processes to execute the
function need to be re-engineered. In many cases, the use of digital signatures may require
transforming agency business processes to a new service delivery model, involving some
degree of process re-engineering. In many instances, this can result in significant
streamlining. Rarely can digital signatures simply be "plugged in" or "switched on."
The public may have concerns about electronic transactions that PKI technology may not
initially alleviate. People are naturally uncomfortable with change, and public key
technology is not yet widely understood and it is not perceived as having demonstrated
"trustworthiness." To deal with these concerns, agencies should develop a public
information plan or comparable document covering the agency's design, implementation, and
presentation of the electronic application. The plan should seek stakeholder input early in the
process of developing electronic transaction systems using public key technology, and it
should establish and communicate the strengths which PKI technology brings to ensure
security and privacy, promote the availability of electronic communications, and reduce risks
associated with their use.
The Social Security Administration, which interacts with the public on a regular basis,
published a report on this subject in September 1997 called "Privacy and Customer Service in
the Electronic Age" (available online at http://www.ssa.gov). The report expands upon the
issues discussed above and can help agency officials better understand how to deal with
public concerns over electronic interactions.
3
As cited earlier, public key technology and digital certificates (which bind the identity of a
party to his, her, or its public key) can be used to support authentication, encryption, non-
repudiation, and data integrity. Several services are available through the use of a PKI, for
example:
• A user can authenticate himself or herself to another party, typically a server, by digitally
signing a challenge phrase (supplied by the server) with the user's private signature key.
The server can use the public key in the user's digital certificate to validate the user's
signature on the challenge phrase and thus authenticate the user.
• Web servers frequently have digital certificates issued to them which can be used to
authenticate the server to a user and create an encrypted communications session that can
be used to protect any shared secret information including Personal Identification
Numbers (PENs) or passwords. Such an "encrypted session" can prevent a malefactor
from taking it over (sometimes called "hijacking") after the session has begun.
• When web servers and clients both have digital certificates, mutual strong authentication
can be achieved, and each party can authenticate itself to the other.
• A document or file may be digitally signed using a party's private signature key, creating
a "digital signature" that is stored with the document. At a later date, anyone can validate
the signature on the document using the public key from the digital certificate issued to
the signer. Validating the digital signature not only confirms who signed it, but also
ensures that there have been no alterations to the document since it was signed.
• Similarly, an e-mail message may be digitally signed using commonly available client
software that implements an open standard for this purpose, such as Secure Multipurpose
Internet Mail Extensions (S/MIME). Validating the signature on the e-mail can help the
recipient know with confidence who sent it, and that it was not altered during
transmission.
The X.509 Version 3 standard for digital certificates provides specific bits which can be set
in a certificate to ensure that the certificate is only used for specific services (signature,
authentication, encryption). Applications may or may not conform to the X.509 Version 3
standard and may or may not honor the bit settings in the certificate, so care should be taken
to determine this prior to purchasing a specific product. Further, some communities of
interest may set these bits differently while still complying with X.509 Version 3; thus, when
different communities of interest desire to interoperate, they should establish how these bits
are set to facilitate interoperability.
The guidance document is also intended to raise the awareness of agencies about
uncertainties or concerns related to the use of public key technology. Thus a decision to use
the technology, or how to implement it properly, can be fiilly informed.
4
Finally, this document focuses on the use of public key technology for digital signatures and
authentication, but a PKI established for those purposes can also be used to provide end-user
to end-user confidentiality or privacy through the use of encryption certificates. That is an
example of the extensible nature of public key technology.
3. Access Certificates for Electronic Services
Agencies wishing to employ digital certificates should first consider using the capabilities
provided by the Federal Technology Service (FTS) of the General Services Administration
(GSA) through contracts under the Access Certificates for Electronic Services (ACES)
program. ACES is a very convenient contract vehicle for:
(a) obtaining PKI services (including certificate issuance from a vendor PKI
established especially for the purpose) for transactions with the public or with
agency trading partners;
(b) obtaining vendor services to set up a vendor or agency-run special-purpose PKI
covering agency employees, contractors, or the public; and
(c) obtaining vendor services to PKI-enable applications programs to accept
certificates regardless of source.
In late 1999, the ACES program placed three contracts with large consortia, which included
leading PKI and IT firms, and which provided competitive prices for digital certificate
issuance and use. Agencies can make use of the ACES contracts simply by entering into an
interagency agreement with FTS/GSA, and then let FTS manage the contract. Agencies are
encouraged to consider this alternative as they review the guidance contained in this
document. Agencies are encouraged to especially inquire as to the costs associated with
enabling applications to use ACES, because the total costs associated with employing ACES
falls well within the agency threshold for saving money through the use of electronic
transactions requiring strong authentication. Further information and points of contact can be
found at http://www.gsa.gov/aces.
4. Using This Document
Federal agency officials should determine if the use of public key technology for digital
signatures and authentication makes good business sense. Agency considerations of cost, risk,
and benefit, as well as any measures taken to minimize risks, should be commensurate with
the level of sensitivity of the transaction. This determination often needs to be made on an
application by application basis, with the understanding that once a PKI is in place, it can
serve multiple applications. This document contains questions which Federal agency
officials should answer while evaluating a potential application. The questions cover five
main elements:
(1) the benefits derived fi-om implementing and using digital signatures for an
application;
(2) the costs;
(3) the risks;
5
(4) how to compare the benefits, costs, and risks to arrive at a decision; and
(5) what issues to consider in implementing the decision.
Associated with each question is additional material (labeled "discussion") to help provide a
more complete context. There are questions about policy, technical, business, and legal
issues, which address concerns of an agency's technical staff as well as its senior policy or
decision-makers. Where this is likely to be the case and it is not clear from the context, the
discussion material related to the question so indicates.
The questions (each of which starts on a new page) are presented in an order that anticipates
how an agency may evaluate a potential application of public key technology involving
digital signatures or authentication to an existing electronic process. Since one size cannot fit
all, agencies certainly have the discretion to deal with the questions in a different order.
Moreover, there may be circumstances where no electronic process currently exists but may
be developed; in that case, the questions should be helpful in evaluating the potential
application of this technology as the electronic process is designed. Finally, the questions
help agencies compare PKI technology with other mechanisms such as PINs that supply some
of the functionality provided by public key technology.
5. Summary
Many Federal agencies are implementing, or considering opportunities for implementing
public key technology applications to improve the delivery of services both internally and to
outside parties and to improve work processes with existing business partners. Recognizing
these opportunities, and seizing them in a disciplined, thoughtful way, may involve accepting
significant risks, as discussed in more detail below. Agencies should assess the risks
carefully, seek to minimize them, and consider whether the risks they take are commensurate
with their legal obligations and their duties to the public. Risks to be considered include
those resulting from the use of digital signatures as well as the potentially higher risks
resulting from continued use of other mechanisms such as paper based processes.
Fortunately, agencies wishing to seize such opportunities are not alone. They may call upon
the experience and expertise represented by the many agencies that participate in the Federal
PKI Steering Committee, the activities of which are reported in Access with Trust and The
Evolving Federal Public Key Infrastructure and on the Steering Committee web site,
http://gits-sec.freas.gov. Several of these agencies have already succeeded in applying the
technology to a wide spectrum of applications. This guidance document aims to support
agencies considering when and how to implement applications using public key technology
for digital signatures and authentication.
6
Question 1. What are the benefits, direct and indirect, financial and non financial, objective
and subjective, of using digital signatures for the proposed application?
Dl.O Discussion
The context of this question includes converting existing electronic processes to use digital
signatures; developing electronic processes using digital signatures where the existing
process is manual; and considering external, inter- and intra-agency applications for the use
of digital signatures. Further, as the question implies, benefits come in many forms. It is
important for all of the benefits to be identified so that a fair comparison of costs and risks
can be made. (For purposes of this discussion, "electronic processes" employ application
software, so using digital signatures with an electronic process is tantamount to enabling the
application software to accept such digital signatures. That, in turn, requires the application
software to interact with the PKI under which the digital certificates are issued to end
entities.)
Many of the benefits cited below accrue from the use of electronic processes, rather than
from the use of digital signatures per se in those processes. However, as discussed above,
public key technology can create a trusted environment that promotes the use and growth of
all electronic processes, so it is appropriate to attribute these benefits in substantial measure
to public key technology. Potential benefits that should be evaluated include:
Dl.l Time Savings
Use of electronic processes and digital signatures can reduce the time required to
process information collections from sources inside or outside the agency. These may
involve claims for financial or other benefits, bids on procurements, or simply
inquiries involving private or proprietary information. Reduced response time
benefits the agency by reducing per-transaction processing costs. The recipient
benefits in ways that it may be difficult to measure, but which can be categorized as
"increased responsiveness of Government to its citizens."
D1.2 Cost Savings
The long-term cost of performing agency business may be reduced. These cost
reductions result from decreased transaction time and cost, increased accuracy and
productivity, more effective use of staff in addressing agency priorities, reduced
maintenance or operating costs associated with paper-based systems, and better and
more trusted ways of allowing users to pay for services provided. These effects
become more pronounced as the number of transactions increases.
D1.3 Enhanced Service
7
The availability and accessibility of agency processes to users inside the agency, to
the public, and to other outside entities is enhanced. The strong authentication, which
digital signatures provide, allows the agency to supply broader service and to promote
Administration goals and objectives to a wider audience. With the burgeoning use of
the hitemet and the increasing sophistication of the American public in the use of
electronic processes, microcomputers, and networks, electronic accessibility to
Federal agencies provides an opportunity for a member of the public to contact a
Government agency when and where it is convenient for the individual, hi effect,
Government can serve the public 24 hours a day, seven days a week. Many private
companies are already operating in this fashion over the hitemet.
D1.4 Improved Quality and Integrity of Data
With electronic processes using digital signatures, the quality and integrity of data
collected are substantially improved. This reduces cost and improves process
efficiency. For example, unlike paper processes, online forms can include field edit
functions and immediate data integrity and consistency checks. Thus, errors can be
detected during input and corrected at that time (i.e., before transmission), saving
agency and customer time and effort. This approach also ensures the customer that
the information he or she is providing will be accepted and that no errors were
inadvertently introduced as a result of data-entry mistakes. These errors could be
caused by poor penmanship on the part of the customer or by typographical errors on
the part of the Government employee. Moreover, digital signatures provide strong
authentication processes between the user and the system serving the user that help to
assure users that it is safe to supply private information electronically and to receive
the full benefit of electronic transactions.
These types of interactions are already becoming commonplace in the online market.
Software providers encourage electronic registration of their products using query
screens that prompt the user for information. The screens identify fields that must be
filled out, provide options for entries, and generally check to ensure the fields contain
legitimate information (e.g., checking that a phone number includes an area code;
verifying that the zip code corresponds to the telephone area code; and so on). The
organization and the user benefit when a single transaction with a customer requires
only one interaction to satisfy that customer's needs.
8
Question 2. How much will it cost to (a) either convert an existing electronic processing
system (that is, a system which processes information electronically or digitally) to use
digital signatures, or convert an existing non-electronic process to an electronic one using
digital signatures; and (b) operate such a system after conversion?
D2.0 Discussion
Federal agencies perform this type of analysis whenever they consider implementing
information technology in their work processes. Many of the requirements and
considerations are discussed in 0MB Circular A- 130 and its references, or in requirements
developed by each agency to implement A- 130 and the Computer Security Act of 1987. This
includes evaluating aspects such as the full life cycle cost of the system using digital
signatures, system maintenance, facilities, training, backup, auditing, personnel needs, and
other factors. Agencies should apply the same analytical methodology in evaluating the use
of digital signatures for their electronic processes. The evaluation should touch upon the
following issues in establishing expected costs:
D2.1 Required Level of Trust
The cost of implementing an application using digital signatures will depend on the
level of trust (or assurance) that the application will be required to provide. Trust in
this context means with what level of certainty the application meets the first three
principles of identification and authentication, data integrity, and non-repudiation that
are discussed in the Background section (2.0). The level of trust enables agencies to
evaluate how well the system can defend against threats. The agency needs to
establish how the required level of trust affects implementing digital signatures in the
application (and attendant costs), and whether the technology should be used on a
"per-transaction" or other basis. Agencies should consider:
(1) the nature of the transactions (e.g., number or frequency, and amount of
information transferred per session), especially those containing information
of programmatic or enforcement importance to the agency, financial
information, or data requiring protection for privacy or proprietary reasons or
otherwise particularly subject to the risks discussed in section D3;
(2) relevant statutory, regulatory, or other requirements, and trading partner
practices;
(3) the level of assurance, if any, that the application currently possesses without
digital signatures, measured against the principles of Section 2.0, and whether
that level warrants changing;
9
(4) the scope of the appHcation, especially whether it is anticipated to grow,
because growth may create financial or other pressures that digital signatures
can better address;
(5) the nature and expectations of the users, including their demographics and
access to electronic methods of interaction; and
(6) the view of key stakeholders, such as privacy and consumer advocates.
D2.2 Integrity of Public and Private Keys
Public and private keys must be managed properly to ensure their integrity. The key
owner is responsible for protecting private keys. The private signature key must be
kept under the sole control of the owner to prevent its misuse. The integrity of the
public key, by contrast, is established through a digital certificate issued by a
Certification Authority (CA, discussed further below) that cryptographically binds the
individual's identity to his or her public key. Binding the individual's identity to the
public key corresponds to the protection afforded to an individual's private signature
key.
Compromise or loss of a private signature key could have financial consequences if a
user employing that signature key is conducting monetary transactions. A PKI
includes the ability to recover from situations where an individual's private signature
key is lost, stolen, compromised, or destroyed; this is done by revoking the digital
certificate that contains the private signature key's corresponding public key
(discussed further below). The user then creates or is issued a new public/private
signature key pair, and receives a new digital certificate for the new public key.
These activities incur transaction costs.
The Certification Authority (CA) plays a critical role in ensuring the integrity of
public keys in the PKI. Upon being presented with proper evidence of identity
(usually through a separate entity called a Registration Authority), the CA issues a
digital certificate which contains the applicant's public key, identity, and other
information (such as duration of the certificate), all signed by the CA's private
signature key. The certificate may then be distributed or placed in publicly available
databases, called repositories. The CA operates under a Certificate Policy (CP) and
Certification Practices Statement (CPS) that collectively describe the CA's
responsibilities and duties to its customers and trading partners. These policies
include how the CA is conducting its affairs in compliance with its contracts and,
where applicable. Federal or State laws. The uses for which a certificate may be
employed depend upon the requirements surrounding its issuance; for example, the
method of identity proofing by the RA before certificate issuance and how well the
private signature key is protected.
The basic issues involving CAs that affect the cost of the application are:
10
(1) Whether the agency should operate its own Certification Authority;
"outsource" that function, such as by employing a CA run by another Federal
agency or one or more private companies (which may include the ACES
contract offered by the General Services Administration to facilitate delivery
of PKI services to agencies); or simply accept certificates signed by other
Federal or commercial sector CAs.
(2) The level of "trusf the agency requires for the certificates to complete the
transaction reliably. This includes determining the level of identity proofing
required for a subscriber to get a certificate; the strength of the cryptography
employed (e.g., key lengths and algorithms); how the corresponding private
signature key is protected; and other factors. Agencies must determine the
required level of trust premised upon several objective or subjective factors,
including:
(a) Statutory requirements;
(b) Administration or agency policy;
(c) Trading partner practices.
(3) Will the CA need to interoperate with CAs run by other Federal agencies or
with commercially available CAs, and if so, how that will be accomplished.
Such interoperability is important if the agency wishes to have the
certificates issued by its CA accepted by other parties, and if the agency
wishes to accept certificates issued by other parties. Considerations include
whether the agency CA will interoperate with the Federal Bridge CA (thus
providing interoperability with all other agency CAs that interoperate with
the Federal Bridge CA), and whether the agency CA will interoperate with
other CAs via another mechanism.
(4) Will the CA need to operate 24X7; how often does certificate revocation
information need to be published, including whether an online process needs
to be in place for that purpose, such as using the Online Certificate Status
Protocol; and is there a need for a local or remote backup CA to continue
operation if the main CA goes down.
D2.3 Quantification of the Consequences of Potential Risks
The use of digital signatures entails potential risks, some of which are known and
understood, others of which are known and less well understood (see Question 3
below), and still others that may not yet be known. The consequences of each risk
may be related in principle to a potential cost to the agency. For example, the agency
may conclude that a higher incidence of fi-aud is likely. This may or may not be true
11
since many believe that the use of public key technology may actually reduce the
incidence of fraud. Depending upon the particular situation and the way an agency
implements its program, the agency may be able to define possible financial impacts
by extrapolating losses due to fraud without digital signatures. To the extent that the
consequences of a potential risk can be identified (per Question 3), an agency should
consider whether its financial impacts can be quantified.
D2.4 Policy, Practices, and Procedures
Policies, practices, and procedures for the use of public key technology need to be
developed for the application at issue. Lideed, the starting place on a policy level for
a PKJ is the development of a CP. If the agency has decided to run its own PKI, it
should prepare a CPS. Writing these documents is likely to consume substantial
resources, but those resources are well spent since they create the entire fi"amework
for the agency's PKI, including the issuance, revocation, and use of certificates.
Beyond the CP and CPS, existing agency policy, practices, and procedures may have
to be altered or amended. Ideally, these processes should apply broadly to an
agency's electronic transactions as a whole, or to classes of transactions, and there
should be some consistency or common elements across the Federal Government.
The most important factors to consider in the development of a CP and/or CPS, and in
any revisions to other agency policies, practices, or procedures, include:
(1) To what extent does the agency require a signature versus another form of
identification for the internal and external process interactions in question;
(2) To what extent does the agency currently accept the use of digital or other
electronic forms of signature for documents submitted within the agency, by
other agencies, or by non-Federal Government parties including by the public;
(3) What auditing is required and what mechanism is employed to support the
electronic and possibly encrypted nature of records;
(4) How the protection of personal information under the Privacy Act will be
ensured. The use of public key technology may require the creation of new
databases containing information that would make some of those databases
"systems of records" under the Privacy Act. For example, when an agency
either contracts for or operates its own Registration Authority, the database
created for identity proofing purposes would be a system of records and thus
would require notice in the Federal Register. Repositories of certificates
maintained by an agency or by a contractor to the agency would also likely be
systems of records. By contrast, however, a repository of certificates run by a
commercial entity separate from the Government, for broader commercial
purposes, but which the agency might access to obtain a person's digital
12
certificate, would not be a system of records. Questions concerning whether a
new database required for the apphcation of public key technology constitutes
a system of records should be resolved with agency counsel and, if
appropriate, the Office of Management and Budget.
(5) The length of time an agency must be able to present and/or validate a
signature on a document. This affects:
(a) The duration for records retention for documents such as certificates and
Certificate Revocation Lists (CRLs);
(b) The form of the electronic document, since once a digital signature is
made, the document cannot be reformatted or otherwise changed without
destroying the signature;
(c) What software and/or hardware may need to be retained in order to
validate a signature made in the past;
(d) Requirements for trusted time-stamp services to determine the date/time of
the signature, and of the documents (certificates, CRLs) needed to validate
the signature in a trustworthy fashion; and
(e) Who should provide this capability? The ability to validate a signature on
a document after the corresponding certificate has expired is an obligation
that could be imposed on the component within the agency responsible for
operating the CA, or on some central authority, which is responsible for
the entire agency PKI. Further, agencies should consider how to ensure
that the entity responsible for providing this service either will continue to
exist or will have some mechanism providing for another party to assume
its responsibilities in the event it ceases to exist.
(6) What the agency may want to require of subscribers (i.e., those to whom
certificates are issued) prior to certificate issuance. For example, it is usually
good practice to have a "subscriber agreemenf in place that the subscriber
manually signs. This agreement describes his or her obligations to protect the
private signature key, and to notify appropriate authorities if it is stolen, lost,
compromised, unaccounted for, or destroyed. Often the provisions of a
subscriber agreement can be placed into other documents (such as an
employment contract, or a security agreement). Agencies may also wish to
consider periodic updating of user agreements, perhaps with wet signatures, as
a security measure.
D2.5 Connectivity to Existing Agency Infrastructure
13
To use public key technology properly in an application, including establishing the
PKI itself, proper connectivity must be provided to the agency's existing electronic
infrastructure. This infrastructure may include extensive mainframe and other "back-
end" information processing systems. Many of the infrastructure's systems employ
security devices such as firewalls aimed at providing proper segregation and security.
Virtually all devices have databases that may need to be used to support a PKI while
maintaining their integrity. Thus, two issues warrant specific consideration:
(1) Identifying the parts of the existing agency elecfronic infrastructure that need to
interface using public key technology and the parts to which an interface would be
desirable but not essential is an important first step. The latter may include
providing capabilities that are not critical to the specific application, but provide
fiinctionality desired by the agency for other reasons. Factors to consider include:
(a) how the application and the PKI will function across security and access
confrol devices such as firewalls;
(b) how the application will interact securely with databases or directories that
exist separate from the application but from which the application must obtain
information (should those databases be replicated to minimize or reduce the
need for such secure access.)
(2) Establishing the costs associated with providing the necessary and the desired
interfaces, including those costs associated with making the fransition to public
key technology. For example, it may be necessary to operate multiple systems
until the new one demonstrates reliable operation).
D2.6 Interoperability with Other Agency Infrastructures
Other connectivity issues which should be evaluated include appropriate cormectivity
to and consistency with (interoperability with) elecfronic infrastructures present in
other agencies, and the Federal (and possibly non-Federal) PKI in general.
Interoperability is a complex issue, which should be considered from several
perspectives:
(1) Policy interoperability or how the "level of assurance" of certificates issued under
the agency's Certificate Policy "map" to those of external parties. Doing such
"policy mapping" depends upon several objective and subjective factors (e.g.,
comparison of identity proofing mechanisms; how private signature key
protection is afforded; strength of cryptography; etc.). The Federal PKI Policy
Authority performs this fijnction for Federal agencies desiring to interoperate with
the FBCA, so that the Certificate Policy of the FBCA becomes the "universal
franslator" of levels of assurance among agencies. In addition to policy mapping,
another element of policy interoperability is ensuring that certificates conform to a
consistent Certificate Profile, which describes the extension fields contained
14
within the certificates, how those fields are to be populated, and how they are to
be interpreted by application software. The National Institute of Standards and
Technology (NIST) has developed a Federal Certificate Profile that is useftil for
this purpose; it can be found by accessing the Technical Working Group web page
through the Steering Committee web page (http://gits-sec.treas.gov).
(2) Technical interoperability comprises several elements:
(a) PKI to PKI interoperability. This is the ability of different CAs either to
cross-certify or to accept some other mechanism (such as Certificate Trust
Lists) so that the users in one PKI domain can accept as trusted (at some
appropriate level of assurance) the certificates issued by another PKI domain;
(b) Application to application interoperability. This is the ability of different
products to accept certificates issued outside their PKI domain, including the
ability to create and process certificate trust paths fi"om the domain of the
relying party to the domain of the certificate issuer, using for example cross-
certificates issued by the FBCA to both domains. It also means mapping
policies using information in the FBCA cross-certificates to allow the relying
party to establish how much confidence he or she should have in the certificate
received from the sender's domain. Further, it means interpreting the
extension fields in X.509 Version 3 certificates in a consistent and compatible
fashion;
(c) Intra-application interoperability. This is the ability of different products to
accept certificates issued by different CA products within their PKI domain.
This can be vexing because CA products differ in the functionality they supply
and the way they supply it. Each CA product generally needs to have an
application "enabled" using a specific "toolkif to accept its certificates.
Once enabled, the application should work with certificates issued by that
product. To have the application accept certificates issued by another CA
requires the application to be enabled with yet another toolkit. While vendors
are working to minimize this need to enable the application for multiple CA
products, there will always be some elements that will require them. For
example, each CA product does encryption key recovery differently, so it is
not possible simply to "unplug" one CA product and "plug in" a new one
seamlessly. The ability to do "plug and play" with many PKI products will
improve with fime, but it is unlikely that the interoperability problem will
vanish;
(d) Directory interoperability. This is the ability to supply directory services that
allow certificates and CRLs to be found and used to the PKI and applications.
15
In summary, an agency should determine what poHcy and technical interoperability is
needed or may be needed with external parties, and then consider which products best
fulfill those needs given the factors set forth above.
D2.7 Records Management
Proper management of electronic records maintained or used, as part of the
application must be ensured. This entails:
(1) Retaining those records necessary for long-term system operation including,
where appropriate, all certificates or CRLs produced by a CA;
(2) Retaining audit records and other materials necessary to establish proper
system operation at any point in time as required for legal or other purposes;
(3) Ensuring past records stored using certain electronic formats or media remain
recoverable as those formats or media are replaced with newer technology.
For example, the use of 5 % inch floppy disks is diminishing, and the number
of microcomputer systems with 5 % inch disk drives is also declining. This
concern is not unique to public key technology, although the ability to
preserve a digital signature does preclude the approach of simply reformatting
documents, such as changing them from one word processor format to another
word processor format. The digital signature is preserved when the file is
transferred from one medium (e.g., magnetic disk) to another (e.g., optical
media such as CD-ROM) as long as the transfer preserves the original file
with 100 % fidelity.
For a thorough discussion of digital signature records management, the reader is
referred to the guidance issued by NARA.
D2.8 Compliance with PKI Standards
There is no single Federal standard that defines and describes a PKI or the use of
public key technology. There are, however, several standards (Federal Information
Processing Standards (FIPS), American National Standards Institute (ANSI), and
others) that are relevant to public key technology and a PKI. The standards, or a
reference to a web site, from which they may be downloaded, can be obtained through
the agency's Information Systems Security Officer or FPKI Steering Committee
representative (URL http://gits-sec.treas.gov). Since some of these standards are in
the process of revision to reflect the evolving nature of public key technology, it is
important to contact the Steering Committee to ensure the agency's evaluation is
based on the most recent information.
D2.9 Enabling Applications Programs
16
A PKJ is an infrastructure, like a highway. By itself, it does little. It is useful when
applications programs employ the certificates and services that it supplies.
Applications programs either have to be PKI-enabled or PKI-aware out of the box
(which is true of some applications such as secure messaging clients that employ
S/MEME), or they have to be enabled separately. Such enabling may involve using
PKI-vendor "plug-ins" which can be added into the application software, or it may
involve far more detailed programming. Thus, agencies must understand the cost
associated with making their existing applications PKI-enabled, and to ensure the
ability to employ the PKI product or service selected by the agency for the
infrastructure. With respect to interoperability, agencies need to understand that
enabling an application to operate with one vendor's PKI products does not ensure
that the application will also operate with a different vendor's PKI products. Indeed,
at this stage, often the opposite is usually true. However, enabling a product to accept
digital certificates issued to the X.509 Version 3 standard does afford interoperability.
The application can accept such certificates from multiple vendor CAs, assuming that
the certificates honor a consistent Certificate Profile for their extension fields.
D2.10 Apprising Affected Parties
Affected entities inside and outside the agency will need to be apprised of the
availability of certificates and PKI-enabled applications. Subscribers to whom
certificates were issued and users who may not hold certificates but may rely upon a
certificate to decide whether or not to allow a transaction to be completed will need to
be trained in their use. This includes processes from registration for certificates, to
certificate issuance, to applications programs that rely on certificates for electronic
transactions to be completed.
D2.11 Additional Statutory Requirements
In changing an existing electronic process to add in the use of public key technology,
or in creating an electronic process using public key technology, agencies need to
consider what additional statutory requirements they may need to meet. These
include provisions of Section 508 of Public Law 105-220 governing providing
Government services to individuals with disabilities.
17
Question 3. What are the risks associated with the use of public key technology for this
application?
D3.0 Discussion
(1) Three areas of risks associated with the use of public key technology are (a) fraud; (b)
failure of the system to fulfill its purpose (service failure or shortfall); and (c) liability.
Agencies considering each area should evaluate risk in two separate contexts. First,
does the use of public key technology create "new" risk? If so, what is its "absolute"
level, that is, the greatest monetary or intangible loss the agency can suffer)? Second,
how does that level of risk compare to the risk already experienced using existing
systems that supply the same service to the public or other entities today? \n other
words, what is the relative risk?
The use of digital signatures may actually reduce risk compared to existing electronic
and paper-based processes. Once a digital certificate has been properly issued, the
ability to impersonate usually reduces to a simple question: can someone get that
party's private signature key used for making his or her digital signature? If not, then
identity fraud becomes extremely difficult. However, this raises an important issue
for the Government: establishing the responsibilities and obligations of all parties in
the new infrastructure, including those of individual users. Procedures must also be
put in place to minimize the potential that a user could successfully repudiate his or
her digital signature, for instance, by claiming that the confidentiality of the private
key has been breached. Depending upon the perceived risk of fraud, this may require
greater expense for initial identity proofing and to ensure proper protection and use of
the private key.
There are reasons to believe that public key infrastructure-based systems have the
potential for substantial public acceptance for transactions in the private sector. Even
if the use of digital signatures exposes agencies' users to new fraud risks and creates
increased uncertainty about prosecuting certain kinds of fraud owing to legal factors,
such uncertainty may diminish with time as legislation is enacted or case law
develops. The risks may be far outweighed by the economic and other advantages
gained. For example, use of credit cards beginning in the 1950s significantly
increased potential and actual fraud compared to the use of checks or other paper
fransactions for exchanging funds. Yet, as history has shown, the public has accepted
that the benefits derived far outweigh the drawbacks. Likewise the potential for
fraudulent use of cellular phones is far higher than for hard-wired phones in one's
home, yet once again, the public has accepted that the benefits of cellular phone use
far outweigh that drawback. Additionally, in both situations, industry has adapted and
developed new controls and technology enhancements to reduce fraud while
continuing to experience tremendous growth in these sectors.
18
Use of PKI technology by Government agencies is not entirely analogous to private-
sector use. Government agencies may not be able to treat fraud as a cost of doing
business in the way that businesses do, and the public may have different tolerance of
risk in transactions involving Government programs than they do in transactions with
private entities. Nonetheless, public use of digital signatures in their personal
transactions is likely to enhance its acceptance for transactions with the Government.
This acceptance can be further encouraged when agencies can demonstrate that they
are taking all reasonable steps to ensure the use of this technology meets standards of
care that are better than those practiced in the private sector. For a thorough
discussion of legal risks, the reader is referred to the guidance issued by the
Department of Justice.
D3.1 Fraud
Concerns have been expressed that the use of digital signatures in lieu of paper
signatures will make it more difficult to prosecute individuals seeking to defraud the
Government. Some people say that an individual who wishes to defraud an agency
may submit a fraudulent claim for benefits, but that individual's signature on the
paper embeds what are called "biometric" or "forensic" elements unique to the
individual. In other words, his or her physical signature on the paper can be shown,
by experts in court if necessary, to be bound to that person.
For digital signatures, however, there are no embedded "biometric" elements. The
binding of the individual to the private/public key pair is done through the RA
described previously using an identity proofing mechanism suitable for the ultimate
intended use of the key pair. Thus, if a person "signs" a fraudulent claim with his or
her private signature key (that is, he or she digitally signs the document), there are no
physical or biometric characteristics which may be linked to that person by
handwriting or other expert. Instead, with a PKI, the quality of the initial identify
proofing and control of the private signature key used to sign documents become the
critical factors, since the certificate issued by a CA relying upon the information
supplied by a Registration Authority binds an individual to a public/private signature
key pair.
For these reasons. Federal agencies plarming to use public key technology for digital
signatures must develop and make known obligations for managing private signature
keys and establish appropriate policy governing their user and protection by
subscribers. Subscribers must understand their obligations, and in some fashion (e.g.,
through a subscriber agreement), attest to that understanding, if they are to be held
accountable in the event of a problem.
Additionally, applications which ask a subscriber to make a digital signature should
be engineered so that: (a) the subscriber is clearly presented with an irrefutable
description of what he or she is doing when asked to click on the button (and enter the
authentication data to unlock his or her private signature key) resulting in the digital
19
signature being made; (b) there are appropriate statements attesting to the intent of the
signer, and then captured on the document that is actually digitally signed; (c) the
document that is actually signed is fully visible and "what you see is what you get" is
honored; and (d) once the signature is made, and the document is sent to its
destination, the destination replies with a "return receipt" that is also digitally signed
by the recipient. These are considerations that strengthen the ability of the relying
party to hold the signer accountable and make it more difficult for the signer to
repudiate the transaction).
To provide additional signature strength, the relying party may require that signatures
only be made using private signature keys created and stored on hardware tokens
meeting appropriate FIPS requirements, and that applications programs (and the
operating system on which they run) employ standards that make it more difficult for
malicious code to be present or go unnoticed.
In summary, a robust digital signature implementation would ensure that: (1) the
individual can be strongly linked to a particular transaction so that the signature
captures the entire document, not just isolated elements such as the answers to
questions held in a separate file; (2) it can be demonstrated that the individual
intended to sign the document; (3) knowledge can be demonstrated that the individual
knew exactly what he or she was doing when the digital signature was made); and (4)
a digitally signed receipt is sent after the transaction, ideally reciting the relying
party's view of exactly what was signed and the intent of the signature.
D3.2 Service Failure or Shortfall
An important goal of using electronic processes with public key technology is to
ensure parties seeking Government services get those services quickly, efficiently,
and with trust. But a service failure or shortfall having an adverse effect on an
agency's ability to meet its legal obligations can result from factors such as poor
design or implementation of the software providing or using the public key
technology, or inadequate training of the service providers or users. Any process,
electronic or paper, is susceptible to a range of risks, some of which are similar,
others of which differ. Electronic processes may possess flaws in hardware or
software that affect data integrity or availability, or impede data collection. Paper
processes can be cumbersome, slow, and difficult to manage with respect to data
security and availability. The important thing is that an agency does its best to
identify the risks, both in new electronic processes and in extant paper processes. In
this way, informed decisions can be made about making the transition from the latter
to the former. The use of electronic processes in general, and those with public key
technology in particular, creates risks that the system will not fiinction as planned. At
the same tirt^e, the level of service of paper-based systems is not high, and they too
can fail to satisfy customers in quality or speed.
20
Agencies will need to develop methods to manage system failures or curtailments and
deal with customer inquiries and complaints related to electronic transactions that use
public key technology. Factors to consider here are the consequences to users of
service delay or interruption; likelihood of delay or interruption; and ability to use a
separate system until the electronic processes using public key technology are
restored.
A related and equally important issue is the need to incorporate electronic services
using digital signatures within the scope of agency disaster recovery plans. At a
minimum, agencies should consider establishing backup sites for their key PKI
components (RA, CA, directories) that supply the services necessary for applications
programs to use certificates.
D3.3 Liability
Whenever a Federal agency interacts with outside parties, it must face the question of
how its actions make it legally liable to affected parties. The use of public key
technology is no different in this respect from the use of other technologies. This
matter is addressed in the DOJ guidance cited earlier.
21
Question 4. How should the benefits determined in response to Question 1 be compared to
the costs established in response to Question 2 and the risks discussed in response to
Question 3?
D4.0 Discussion
This question involves a policy judgment, especially where the benefits contain both
quantitative and non-quantitative elements. The agency must select the proper
method to compare or weigh the costs against the benefits and come to an appropriate
business decision about whether an electronic process using digital signatures is
preferable to one that does not use that technology. An authoritative discussion of the
costs, risks, and benefits of electronic processes appears in 0MB 's procedures and
guidance on the implementation of GPEA (65 Fed. Reg. 25508 (May 2, 2000)).
Some considerations that the agency should keep in mind as it performs this
evaluation relative to the use of digital signatures are:
D4.1 Inherent Value
Ideally, the use of digital signatures should save the agency money in the short or long
run. However, there are circumstances where the use of digital signatures may be
warranted even without such savings. For example, building the good will of the
public and elected State and local officials by demonstrating that Government
services can be supplied more quickly and effectively in a trusted electronic
environment may warrant substantial up-front and continuing costs. Li that case, the
issue boils down to whether there is sufficient value to the Government and citizens
for the money being spent on the service, not just whether the service per se is saving
the Government money. Agencies should consider whether an additional expense
would be justified by increased or enhanced service.
D4.2 Part of a Bigger Whole
Agencies may find it useful to evaluate costs and benefits not simply on an
application basis, but on an overall service delivery basis. The costs associated with
establishing and running a PKI for digital signatures may support multiple
applications and multiple agency programs, and therefore the same PKI over time will
serve increasingly large numbers of customers and other capabilities such as
encryption. Consequently, up-front development costs of the PKI may be evaluated
as something to be incurred over time (like maintenance costs) and in the context of a
total service delivery program.
D4.3 Public Acceptance
Even if the use of digital signatures exposes agencies to new fraud risks and creates
increased uncertainty about prosecuting certain kinds of fi"aud as a result of legal
22
factors, such uncertainty may diminish with time as legislation is enacted or case law
develops. The risks may be far outweighed by the economic and other advantages
gained. For example, use of credit cards beginning in the 1950s significantly
increased potential and actual fraud compared to the use of checks or other paper
transactions for exchanging funds. Yet, as history has shown, the public has accepted
that the benefits derived far outweigh the drawbacks. Likewise the potential for
fraudulent use of cellular phones is far higher than for hard-wired phones in one's
home, yet once again, the public has accepted that the benefits of cellular phone use
far outweigh that drawback. Additionally, in both situations, industry has adapted and
developed new controls and technology enhancements to reduce fraud while
continuing to experience tremendous growth in these sectors.
D4.4 OMB A-130 Examination of Risk
The proposed application must meet the risk-based standard set forth in the Computer
Security Act of 1987 and OMB Circular A-130, Appendix HI, namely, is any benefit
associated with the use of digital signatures for an application "commensurate with
the risk and magnitude of the harm from the loss, misuse, or unauthorized access to or
modification of the information?" This guidance provides substantial flexibility to
agency managers. It recognizes that one size does not fit all, and that a sensible
business application of digital signatures by an agency should recognize that agency's
specific situation in managing data.
23
Question 5. What are the critical implementation issues that an agency should consider as it
seeks to implement and use a PKIfor digital signatures?
D5.0 Discussion
The introduction of public key technology requires considerable planning and may
necessitate changes in business practices and service delivery models. Below is a checklist of
the most important issues that agencies should consider in implementing and using a PKI for
digital signatures. For each item, brief specific guidance is provided.
D5.1 Prepare a Certificate Policy and, if applicable, a Certification Practices
Statement. These are the policy framework documents for the entire PKI, and they
create the disciplined environment necessary for parties wishing to rely on certificates
issued by the PKI. These documents in effect "map" the agency's business model for
electronic transactions to the PKI, setting forth what types of certificates the agency
will issue, purchase, or accept for its business needs. The CP should be prepared in
PKIX Part 4 format (also known as "Chokani/Ford" framework), which lists all of the
■ issues that the organization should consider. If the PKI serves multiple applications,
and each application has a different entity responsible for it, then it is important to
identify which organizational component has responsibility for developing and
keeping up to date the CP and CPS so as to meet the needs of each application the
PKI supports. The agency needs to create a CPS only if it is going to operate its own
CA or have a contractor do it on behalf of the agency. Some CPS preparation may
still be required if the agency obtains PKI services only; in that case, the agency will
need to ensure that provisions of the CPS prepared by the service offerer are suitable
for the agency's needs. Agencies should identify the critical employees who will
actually run the PKI software, and be responsible for safeguarding and using the CA
signing key.
D5.2 Decide what directory services are required by the applications that the PKI is
intended to serve, and ensure they are available or are obtained. Such services
allow the CA to publish CRLs so that users can readily discover them and allow users
to easily obtain certificates for digital signature validation or encryption purposes.
The certificates may not need to be obtained from this service if the certificates are
conveyed as part of the transaction as with S/MIME clients.
D5.3 Ensure that the need for agency PKI interoperability with parties external to
the agency is established and addressed. Use of the Federal Bridge CA will probably
provide the most efficient mechanism to achieve interoperability with other Federal
agencies. Agencies should consider the CP honored by the FBCA in preparing their
Certificate Policies.
D5.4 Ensure that as the PKI is developed, agency applications are made PKI-
enabled (or purchased PKI-enabled). Application programs that use the PKI should
24
be planned concurrent with the selection and implementation of the PKI. This
procedure provides the greatest flexibility since both the infrastructure and the
applications programs can be adjusted to fit. This effort includes ensuring that
applications programs can create appropriate certificate trust paths; process those
paths; and find and check certificate revocation information through Certificate
Revocafion Lists (CRLs), Online Certificate Status Protocol (OCSP), or validation
authorities. Moreover, this is the time to ensure that the applications contain the
proper user "interface." They should fulfill the legal requirements to minimize risk
and provide information suitable for later litigation, such as appropriate jurats, notices
to users about the meaning of their making a digital signature, and so on.
D5.5 If practical, implement the PKI and applications in stages rather than all at
once, hicremental implementation provides maximum opportunity to "learn as you
go" and make adjustments as the process proceeds. Moreover, it allows the agency to
scale up such functions as a "help desk" as the number of users increases, rather than
having to start with a large help desk, which can be manpower intensive.
D5.6 Where practical, integrate PKI registration processes into established
personnel or security practices. Agencies can allow employees to register to obtain a
digital certificate when they obtain an agency identification credential, are certified or
qualified to perform a function, or get a security clearance. This approach also has
the advantage of allowing an agency to place into standard employment or security
paperwork the subscriber agreement, which an employee must sign as a condition of
getting the digital certificate. It also supports periodic updates to the agreement if that
is determined to be necessary. Finally, this approach is consistent with the points in
D5.5 concerning incremental ramp-up.
D5.7 Identify (and act upon) requirements to make the PKI software, directories,
and applications programs operate through firewalls and routers. For example,
many PKI programs require certain TCP/IP ports be available (open). Executing PKI
services through firewalls may require obtaining approval of system security
personnel.
D5.8 Decide whether to employ CRLs, OCSP, or a "Validation Authority"
approach for publishing or making available certificate revocation information.
The CRL approach is employed by most commercially available software today; the
OCSP approach is analogous to the current credit card model that is used extensively;
the validation authority approach, for which there are also commercial products
available today, involves establishing a central location into which certificate
revocation information is published from multiple CAs to facilitate certificate status
checking. In establishing conditions that require certificate revocation, agencies
should determine and balance the trade-off between a stringent policy that results in a
large number of revocations, and a less stringent policy that results in fewer
revocations. Greater number of revocations can have an adverse impact on the
25
performance of the PKI, especially if CRLs are used as the mechanism for conveying
information on certificate status to applications.
D5.9 Decide whether to employ an online (e.g., HTTP-based) or off-line (e.g.,
S/MIME) functionality — or both. S/MIME (Secure MIME) is an open standard for
messaging (e-mail) which includes digital signatures on documents and messages, but
it does not provide for an interactive environment. By contrast, browser-based
models support interaction but do not yet have open standards reflecting how HTML
or XML pages are digitally signed. All such solutions currently available employ
proprietary approaches and thus may not be interoperable between products. Efforts
are underway to establish an open standard for XML digital signatures, but how
quickly that will be completed is uncertain.
D5.10 Establish who will fulfill audit roles for the PKI. These roles may reside
within the office of the agency's Chief hiformation Officer; within the Lispector
General's office; within the office responsible for information security; or somewhere
else,
D5.11 Address any liability issues that warrant consideration. This includes stating
what liability, if any, the agency is able and willing to incur in the use of certificates it
issues, and if so, under what circumstances. Generally speaking, the agency PKI
should be viewed as another way to convey or preserve trust between transacting
parties (established pursuant to other relationships such as contracts or regulations),
rather than creating trust per se.
D5.12 Resolve how to deal with validating a digital signature well after it is made.
All of the information required to validate a digital signature after the relevant
certificates have expired should be available. This includes the expired certificates
and the CRLs or other information showing that the certificates were valid at the time
the signature putatively was made. It also includes deciding who is responsible for
providing long-term signature validation services. That is, should the organization
responsible for relying on that signature be able to perform the validation, or should
the infi-astructure provide that capability "automatically"? Answering these questions
requires understanding about how long the agency wishes to be able to validate a
signature, and whether it is willing to accept something other than original signature
validation. For example, the agency could decide to accept the validation of a
signature made by a digital archivist that the signature was validated as of some date
subsequent to its having been made. Indeed, as the cryptographic strength of a digital
signature diminishes with time, it may be necessary to have a trusted party
(sometimes called a "digital archivist") oversign the original document (and original
signature) periodically, using a signature with stronger cryptography.
26
Appendix (1): Description of Public Key Technology and
the Public Key Infrastructure
Al.O Public key technology and a PKI depend upon complicated mathematical concepts, but
their effects are simple and understandable. When a Federal agency (or employees of such an
agency) starts to use the PKI, the agency (or an employee of that agency — call that person
"Bob") begins with a pair of "keys," which look like very long character strings and are
actually digital representations of very large numbers. These keys are either generated by
Bob using a local cryptographic module or provided through trustworthy mechanisms,
subject to certain mathematical requirements. One of these keys is secret (private) and the
other is published (public).
Al.l The essence of public key technology is that messages or transactions authenticated or
encrypted using one of Bob's keys can only be verified or decrypted using his other key.
Thus, when Bob uses his private signature key to sign an electronic message or other
transaction digitally, anyone who knows Bob's corresponding public key can verify Bob's
signature. A similar method using public key technology can be used to encrypt messages for
confidentiality as they transit an open network such as the Internet.
A1.2 The PKI uses special digitally signed messages (called "certificates") to bind Bob's
identity to his public keys. A digital certificate is issued by a trusted "Certification
Authority" (CA) and signed using that CA's private signature key. When someone else (call
her "Alice" — she may be a private citizen, a company, a public interest group, or some other
entity seeking to interact with a Federal agency, or she may even be an employee of that
Federal agency or a different agency) wants to obtain with certainty Bob's public key, she
gets Bob's certificate. Where or how Alice gets Bob's certificate is not important - she may
get it from Bob in person, or from an online "repository" for certificates, or from Bob's
homepage on the World Wide Web, or from Bob's credit card issuer; once she gets it from
whatever source, Alice checks the certificate by validating the CA's digital signature. Alice
now knows Bob's public key and name with certainty and can validate any messages sent to
her, which were signed with Bob's private signature key. These transactions may be
conducted with assurance even though Bob and Alice may have never met; and although they
sound complex, they can be done automatically by the underlying network of computers with
no burden placed on Alice or Bob.
A1.3 To validate the CA's signature on Bob's certificate, Alice must first know the public
key of Bob's CA. Alice always knows the public key of at least one CA that she trusts. CAs
may issue certificates to each other. If Alice does not know the public key of Bob's CA, she
may still be able to find a certificate issued by a CA whose key she does know, that certifies
the public key of Bob's CA. In essence, a CA Alice trusts "vouches" for one she does not
know. Much of the challenge of building a robust global PKI is in the management of
certificates between CAs, as well as the software and infrastructure that automate the process
of building and validating these trust chains of certificates.
27
A1.4 As a general matter, good security practices will ensure Bob has different public-
private key pairs for signature and confidentiality uses, and to reflect his different roles (e.g.,
as an agency official, and as a private citizen and consumer). This is analogous to a person
having different passwords for use on different computer systems, or different Personal
Identification Numbers (PINs) for use with different financial accounts.
A1.5 The scientific, academic, and business communities recognize that the capabilities
described above provide the best way to replace handwritten signatures in the electronic
world, to authenticate identities securely, and to maintain confidentiality on open networks.
Realizing this vision of transacting electronic business with security and privacy requires that
the various implementations of public key technologies work together smoothly and in a
fashion transparent to the user — which is one of the goals of this document.
A1.6 Finally, it is useful to describe briefly the PKI itself The PKI is not simply software or
hardware. It is an infrastructure, that is, a combination of products, services, facilities,
policies, procedures, agreements, and people that provide for and sustain secure interactions
on open networks such as the Internet. It is not a single monolithic entity, but a distributed
system in which the component elements may include public key infrastructures that are
interoperable and interconnected. The infrastructure provides assurances that information is
protected while being entered, during transit, and when stored. The underlying technology is
already developed by private industry and is being marketed and used commercially. The
PKI promotes interoperability among commercial products and the early integration of
security features into those products.
A1.7 The PKI can be likened to elements of the telephone network. When one wants to
contact someone else, it is necessary to access a phone directory or an information operator to
get that person's telephone number — analogous to the role that a directory (run by the CA or
some other entity) plays in supplying a digital certificate of the person to be contacted. When
someone moves to a new location and changes telephone numbers, the infrastructure must
adjust its information to reflect that fact. When you want to know the number of the person
who has dialed you, "caller-id" provides that — another part of the telephone network
infi-astructure analogous to the authentication process in public key technology.
' A1.8 Finally, for a complete description of public key technology and its relationship to
electronic transactions, two useful references are Secure Electronic Commerce by
Ford/Baum, and Applied Cryptography by Schneier.
28
Appendix (2): Description of Public Key Certificates and
the Certification Process
A2.0 The PKI employs a Certification Authority (CA) to provide digital certificates binding
the identity of an individual to his or her public keys. (An individual may have more than
one public key — for example, for acting as an agency official or as a private citizen — but a
digital certificate includes a single public key.) A separate entity, called a "Registration
Authority" (RA), may be used to certify the individual's idenfity to the CA so that the CA
will issue a digital certificate.
Thus, for a user (who is known as a "subscriber" in this context), the process of getting a
digital certificate for the first time may entail:
Step 1 : Generating (or having someone generate for the user) a key pair containing a
public and private component; if someone other than the user generates the key pair,
then the subscriber incurs some risk of misuse since his or her "private" key is known
by at least one other entity;
Step 2: Going to the RA (which may or may not be part of the CA) with proof of
identity and a copy of the public key; in some cases, where the required level of
"idenfity-proofing" is not high, it may be possible to do this online with appropriate
safeguards such as those envisioned in the GSA Access Certificates for Electronic
Services (ACES) effort;
Step 3: At the RA, physically signing some paperwork (so that a physical signature is
on file), which accepts for the subscriber the responsibility for the protection of the
private signature key (corresponding to the public key) and its use.
A2.1 After following its procedures to verify the identity of the individual requesting a
digital certificate, the RA communicates electronically with the CA who issues the digital
certificate (signed with the CA's private signature key) binding the subscriber's public key to
his or her identity. The CA then usually places the certificate in a public database, called a
repository, which may hold certificates issued by many CAs. Repositories can be replicated,
be online, and be freely accessible, with much less protection than CAs require.
A2.2 When a user (Alice) needs to communicate with another user (Bob), Alice obtains
Bob's certificate containing his public key from a repository. Bob's certificate is signed
using the private signature key of the CA. Alice then verifies the CA's signature on Bob's
digital certificate using the CA's public key, and recovers Bob's public key. These fiinctions
are normally done automatically by the software in a fashion transparent to the user. Note
that if someone from outside this process were successful in surreptitiously substituting into a
repository's data base a bogus certificate for Bob with a different public key, the signature on
the bogus certificate would not validate with the CA's public key because it was not signed
29
by the CA's private signature key. This is an example of the safeguards embedded within
pubHc key technology. It does not matter where or how Alice gets Bob's certificate (Bob
could even physically hand it to her on a disk), since it is the CA's signature on the certificate
which authenticates it.
30
.p-
Technical Publications
Periodical
Journal of Research of the National Institute of Standards and Technology — Reports NIST research
and development in those disciplines of the physical and engineering sciences in which the Institute is
active. These include physics, chemistry, engineering, mathematics, and computer sciences. Papers cover a
broad range of subjects, with major emphasis on measurement methodology and the basic technology
underlying standardization. Also included from time to time are survey articles on topics closely related to
the Institute's technical and scientific programs. Issued six times a year.
Nonperiodicals
Monographs — Major contributions to the technical literamre on various subjects related to the
Institute's scientific and technical activities.
Handbooks — Recommended codes of engineering and industrial practice (including safety codes) devel-
oped in cooperation with interested industries, professional organizations, and regulatory bodies.
Special Publications — Include proceedings of conferences sponsored by NIST, NIST annual reports, and
other special publications appropriate to this grouping such as wall charts, pocket cards, and bibliographies.
National Standard Reference Data Series — Provides quantitative data on the physical and chemical
properties of materials, compiled from the world's literature and critically evaluated. Developed under a
worldwide program coordinated by NIST under the authority of the National Standard Data Act (Public
Law 90-396). NOTE: The Journal of Physical and Chemical Reference Data (JPCRD) is published
bimonthly for NIST by the American Instimte of Physics (AIP). Subscription orders and renewals are
available from AIP, RO. Box 503284, St. Louis, MO 63150-3284.
Building Science Series — Disseminates technical information developed at the Institute on building
materials, components, systems, and whole structures. The series presents research results, test methods, and
performance criteria related to the strucmral and environmental functions and the durability and safety
characteristics of building elements and systems.
Technical Notes — Studies or reports which are complete in themselves but restrictive in their treatment of
a subject. Analogous to monographs but not so comprehensive in scope or definitive in treatment of the
subject area. Often serve as a vehicle for final reports of work performed at NIST under the sponsorship of
other government agencies.
Voluntary Product Standards — Developed under procedures published by the Department of Commerce
in Part 10, Tide 15, of the Code of Federal Regulations. The standards establish nationally recognized
requirements for products, and provide all concerned interests with a basis for common understanding of
the characteristics of the products. NIST administers this program in support of the efforts of private-sector
standardizing organizations.
Order the following NIST publications — FIPS and NISTIRs—from the National Technical Information
Service, Springfield, VA 22161.
Federal Information Processing Standards Publications (FIPS PUB) — ^Publications in this series
collectively constitute the Federal Information Processing Standards Register. The Register serves as the
official source of information in the Federal Government regarding standards issued by NIST pursuant to
the Federal Property and Administrative Services Act of 1949 as amended. Public Law 89-306 (79 Stat.
1127), and as implemented by Executive Order 1 1717 (38 FR 12315, dated May 11, 1973) and Part 6 of
Tide 15 CFR (Code of Federal Regulations).
NIST Interagency or Internal Reports (NISilK) — ^The series includes interim or final reports on work
performed by NIST for outside sponsors (both government and nongovernment). In general, initial
distribution is handled by the sponsor; public distribution is handled by sales through the National Technical
Information Service, Springfield, VA 22161, in hard copy, electronic media, or microfiche form. NISTIR's
may also report results of NIST projects of transitory or limited interest, including those that will be
published subsequently in more comprehensive form.
tm
E
lUO
ard
•o
c
Cm
B
©
c
o
E
3
o
o
o
I
ON
OS
00
o
3 >^ S
O DO
g S
4> — J=
P z
o
Si «
o &
Live Music Archive
Librivox Free Audio
Metropolitan Museum
Cleveland Museum of Art
Internet Arcade
Console Living Room
Books to Borrow
Open Library
TV News
Understanding 9/11